Mysterious -E- DXL: incorrect use of identifier

Mystery:

Why does this fail due to -E- DXL: incorrect use of identifier (label is of type string)

containsKey = itemExists(spp, finderClause, "==", label); // WONT COMPILE

 


But this makes it work?

 

 

string labelA = label;
containsKey = itemExists(spp, finderClause, "==", labelA); // WORKS



Try it yourself (DOORS 9.3)



 

 

 

// *****************   CUSTOM TYPE FRAGMENT  **************
struct SPPType {}
struct SPP_FinderClauseType {}
struct SPP_FromClauseType {}
 
bool itemExists(SPPType this,
                 SPP_FinderClauseType finderClause,
                 string registeredCompareFunction,
                 _x queryValue,
                 SPP_FromClauseType fromHere) {
    int qtyFound = 0;
 
    // SOME CODE ...
 
    return (qtyFound > 0);
}
 
bool itemExists(SPPType this,
                SPP_FinderClauseType finderClause,
                string registeredCompareFunction,
                _x queryValue) {
    SPP_FromClauseType defaultFromClause = (SPP_FromClauseType addr_ 1);
    return itemExists(this,                            //-
                       finderClause,                   //-
                       registeredCompareFunction,      //-
                       queryValue,                     //-
                       defaultFromClause );
}
 
 
// *****************   CALLED FROM **************
 
 
struct ParamListType {}
 
void set(ParamListType this, //-
         string        label, //-
         string        value) {
    bool containsKey = false;
 
    SPPType spp = (SPPType addr_ 1); // In reality a custom type
    SPP_FinderClauseType finderClause = (SPP_FinderClauseType addr_ 1); // In reality a custom type
 
    //--------------------------------------------------------------------------
    // Why does this yield -E- DXL: incorrect use of identifier (itemExists)
    //--------------------------------------------------------------------------
 
    // ****** UNCOMMENT THIS *******
 
//    containsKey = itemExists(spp, finderClause, "==", label); // FAILS
 
    //--------------------------------------------------------------------------
    // But if I copy label to labelA it works?
    //--------------------------------------------------------------------------
    string labelA = label;
    containsKey = itemExists(spp, finderClause, "==", labelA); // WORKS
 
    print("set(paramList, " label ", " value ") completed\n");
}
 
print("Earschplittenloudenboomer\n");
 
ParamListType paramList = (ParamListType addr_ 1);
set(paramList, "LabelA", "ValueA");
 
//----------------------------------------------------------
// Output 1
//----------------------------------------------------------
Earschplittenloudenboomer
set(paramList, LabelA, ValueA) completed
 
 
// Extra credit bonus problem
// Can anyone tale a stab at "the decoder ring" for the crazy 
// DXL underscore "wild-card" types? 
// What do the letters mean?
// Does the chosen letter affect adjacent parameters?
 
//----------------------------------------------------------
// Output 2 -- Try different letters and orderings.
// You'll go nuts!
//----------------------------------------------------------
IN f1
p1 = 1
p2 = 2
p3 = 3
IN f2
p1 = 1
p2 = 2
p3 = 3
IN f3
p1 = 1
p2 = 2
IN f3
p1 = 3
//------------------------------------------------------------
 
void f1(_a p1, _b p2, _c p3) {
    print("IN f1\n");
    print("p1 = " (string p1) "\n");
    print("p2 = " (int p2) "\n");
    print("p3 = " (char p3) "\n");
}
 
void f2(_k p1, _m p2, _n p3) {
    print("IN f2\n");
    print("p1 = " (string p1) "\n");
    print("p2 = " (int p2) "\n");
    print("p3 = " (char p3) "\n");
}
 
void f3(_x p1, _y p2) {
    print("IN f3\n");
    print("p1 = " (string p1) "\n");
    print("p2 = " (int p2) "\n");
}
 
void f4(_k p1) {
    print("IN f3\n");
    print("p1 = " (char p1) "\n");
}
 
f1("1", 2, '3');
f2("1", 2, '3');
f3("1", 2);
 
f4('3');

 

 


SystemAdmin - Thu Aug 25 16:46:58 EDT 2011

Re: Mysterious -E- DXL: incorrect use of identifier
llandale - Thu Aug 25 18:12:41 EDT 2011

Far too many DXL errors to compile, even with AutoDeclare on.

Tried various spellings of "label" and it still fails.

You seem to be lining up "label" with parameter _x queryValue. For some reason the "_x resolution routine" doesn't seem to understand its a 'string' since 'value' is the first input parameter into the function. If you change it to "value" it does work, the 2nd string parameter. I am not saying that's logical.

Anyway, it works if you put "string" in front of the call:
... containsKey = itemExists(spp, finderClause, "==", string label)
which seems to be enough to satisfy "_x".

I've seen a couple other weird things associate with input parameters.

  • Louie

Don't see the point of all these 'structures' and 'addr_' and '_x' flexible data types, other than to feel clever and make the code read-only; and it seems not even writable. The lack of comments supports this position. Don't bother claiming it "should" work in a "perfect" world; because it doesn't matter and it isn't. Karma and Murphy are working against you here.

Re: Mysterious -E- DXL: incorrect use of identifier
Mathias Mamsch - Thu Aug 25 18:12:49 EDT 2011

My guess would be that, since itemExists is a function with an _x parameter and 'label' is also a perm, the interpreter tries to somehow pass the perm to the function and tells you cannot do that. That would explain why renaming will work. But it is still weird. Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Re: Mysterious -E- DXL: incorrect use of identifier
SystemAdmin - Thu Aug 25 18:53:39 EDT 2011

llandale - Thu Aug 25 18:12:41 EDT 2011
Far too many DXL errors to compile, even with AutoDeclare on.

Tried various spellings of "label" and it still fails.

You seem to be lining up "label" with parameter _x queryValue. For some reason the "_x resolution routine" doesn't seem to understand its a 'string' since 'value' is the first input parameter into the function. If you change it to "value" it does work, the 2nd string parameter. I am not saying that's logical.

Anyway, it works if you put "string" in front of the call:
... containsKey = itemExists(spp, finderClause, "==", string label)
which seems to be enough to satisfy "_x".

I've seen a couple other weird things associate with input parameters.

  • Louie

Don't see the point of all these 'structures' and 'addr_' and '_x' flexible data types, other than to feel clever and make the code read-only; and it seems not even writable. The lack of comments supports this position. Don't bother claiming it "should" work in a "perfect" world; because it doesn't matter and it isn't. Karma and Murphy are working against you here.

Louie, I'm not sure what the too many compiler errors issue is. I don't have auto declare on and it compiles fine. (provided the one line is commented out).

With the line in I get

-E- DXL: <C:\Program Files\IBM\Rational\DOORS\9.3/lib/dxl/addins/user/_issue.dxl:69> incorrect use of identifier (itemExists)
-I- DXL: All done. Errors reported: 1. Warnings reported: 0.

With the line commented out I get

Earschplittenloudenboomer
set(paramList, LabelA, ValueA) completed
IN f1
p1 = 1
p2 = 2
p3 = 3
IN f2
p1 = 1
p2 = 2
p3 = 3
IN f3
p1 = 1
p2 = 2
IN f3
p1 = 3

Regarding:
Don't see the point of all these 'structures' and 'addr_' and '_x' flexible data types, other than to feel clever and make the code read-only; and it seems not even writable. The lack of comments supports this position. Don't bother claiming it "should" work in a "perfect" world; because it doesn't matter and it isn't. Karma and Murphy are working against you here.

This is only a code fragment with the minimal code in place to illustrate the issue. Stuff like
SPP_FromClauseType defaultFromClause = (SPP_FromClauseType addr_ 1);
is just to get a compilable example without extra source files.
Just to see if it had anything to do with perm clashes, I renamed:

label to paramLabel
value to paramValue
set() to setParam()

and still had the same
-E- DXL: <C:\Program Files\IBM\Rational\DOORS\9.3/lib/dxl/addins/user/_issue.dxl:69> incorrect use of identifier (itemExists)

The entire code that compiles is:

// Experiments
 
 
// Copyright © 2001 Telelogic AB. All rights reserved.
// See DOORS manuals for copying conditions.
// Copy this file to a different location before modifying it.
 
/*
  Experiments
*/
 
/*  Modification history:

    Date:       Who:    Description:
    1st May 95  rmm Added PC-specific path
    3 Sept 96   gv  Use standard filename routines.
*/
 
 
// *****************   CUSTOM TYPE FRAGMENT  **************
struct SPPType {}
struct SPP_FinderClauseType {}
struct SPP_FromClauseType {}
 
bool itemExists(SPPType this,
                 SPP_FinderClauseType finderClause,
                 string registeredCompareFunction,
                 _x queryValue,
                 SPP_FromClauseType fromHere) {
    int qtyFound = 0;
 
    // SOME CODE ...
 
    return (qtyFound > 0);
}
 
bool itemExists(SPPType this,
                SPP_FinderClauseType finderClause,
                string registeredCompareFunction,
                _x queryValue) {
    SPP_FromClauseType defaultFromClause = (SPP_FromClauseType addr_ 1);
    return itemExists(this,                            //-
                       finderClause,                   //-
                       registeredCompareFunction,      //-
                       queryValue,                     //-
                       defaultFromClause );
}
 
 
// *****************   CALLED FROM **************
 
 
struct ParamListType {}
 
void setParam(ParamListType this, //-
              string        paramLabel, //-
              string        paramValue) {
    bool containsKey = false;
 
    SPPType spp = (SPPType addr_ 1); // In reality a custom type
    SPP_FinderClauseType finderClause = (SPP_FinderClauseType addr_ 1); // In reality a custom type
 
    //--------------------------------------------------------------------------
    // Why does this yield -E- DXL: incorrect use of identifier (itemExists)
    //--------------------------------------------------------------------------
 
    // ****** UNCOMMENT THIS *******
 
    // containsKey = itemExists(spp, finderClause, "==", paramLabel); // FAILS
 
    //--------------------------------------------------------------------------
    // But if I copy label to labelA it works?
    //--------------------------------------------------------------------------
    string labelA = paramLabel;
    containsKey = itemExists(spp, finderClause, "==", labelA); // WORKS
 
    containsKey = itemExists(spp, finderClause, "==", (string paramLabel) ); // ALSO WORKS
 
    print("set(paramList, " paramLabel ", " paramValue ") completed\n");
}
 
print("Earschplittenloudenboomer\n");
 
ParamListType paramList = (ParamListType addr_ 1);
setParam(paramList, "LabelA", "ValueA");
 
 
// Extra credit bonus problem
// Can anyone tale a stab at "the decoder ring" for the crazy
// DXL underscore "wild-card" types?
// What do the letters mean?
// Does the chosen letter affect adjacent parameters?
 
//----------------------------------------------------------
// Output 2 -- Try different letters and orderings.
// You'll go nuts!
//----------------------------------------------------------
 
void f1(_a p1, _b p2, _c p3) {
    print("IN f1\n");
    print("p1 = " (string p1) "\n");
    print("p2 = " (int p2) "\n");
    print("p3 = " (char p3) "\n");
}
 
void f2(_k p1, _m p2, _n p3) {
    print("IN f2\n");
    print("p1 = " (string p1) "\n");
    print("p2 = " (int p2) "\n");
    print("p3 = " (char p3) "\n");
}
 
void f3(_x p1, _y p2) {
    print("IN f3\n");
    print("p1 = " (string p1) "\n");
    print("p2 = " (int p2) "\n");
}
 
void f4(_k p1) {
    print("IN f3\n");
    print("p1 = " (char p1) "\n");
}
 
f1("1", 2, '3');
f2("1", 2, '3');
f3("1", 2);
 
f4('3');


{code}

Re: Mysterious -E- DXL: incorrect use of identifier
SystemAdmin - Fri Aug 26 10:47:24 EDT 2011

Here is a more minimal code fragment to illustrate the Mysterious -E- DXL: incorrect use of identifier. No more cracks about "where's the comments" please. This is just a minimal fragment of code to illustrate a mysterious issue.
 

// Experiments
 
 
// Copyright © 2001 Telelogic AB. All rights reserved.
// See DOORS manuals for copying conditions.
// Copy this file to a different location before modifying it.
 
/*
  Experiments
*/
 
/*  Modification history:

    Date:       Who:    Description:
    1st May 95  rmm Added PC-specific path
    3 Sept 96   gv  Use standard filename routines.
*/
 
 
// *****************   CALLED FUNCTIONS  **************
 
bool itemExists(int p1, int p2, string p3, _x p4, int p5) {
    // SOME CODE ...
    return (true);
}
 
bool itemExists(int p1, int p2, string p3, _x p4) {
    int defaultP5 = 5;
    return itemExists(p1, p2, p3, p4, defaultP5);
}
 
// *****************   CALLED FROM **************
 
void setParam(int myList, string paramLabel, string paramValue) {
    bool containsKey = false;
    int p1 = 100;
    int p2 = 1000;
    //--------------------------------------------------------------------------
    // Why does the below yield -E- DXL: incorrect use of identifier (itemExists)
    //--------------------------------------------------------------------------
 
    // ****** UNCOMMENT THIS *******
//     containsKey = itemExists(p1, p2, "==", paramLabel); // FAILS
 
    //--------------------------------------------------------------------------
    // But if I copy label to labelA it works?
    //--------------------------------------------------------------------------
    string labelA = paramLabel;
    containsKey = itemExists(p1, p2, "==", labelA); // WORKS
 
    //--------------------------------------------------------------------------
    // If I cast the string parameter to a string it works?
    // Does DXL have early Alzheimer's disease?
    // It forgot what type paramLabel was?
    //--------------------------------------------------------------------------
    containsKey = itemExists(p1, p2, "==", (string paramLabel) ); // ALSO WORKS
 
    print("set(paramList, " paramLabel ", " paramValue ") completed\n");
}
 
print("Earschplittenloudenboomer\n");
 
int myList = 33;
setParam(myList, "LabelA", "ValueA");
 
 
// Extra credit bonus problem
// Can anyone tale a stab at "the decoder ring" for the crazy
// DXL underscore "wild-card" types?
// What do the letters mean?
// Does the chosen letter affect adjacent parameters?
 
//----------------------------------------------------------
// Output 2 -- Try different letters and orderings.
// You'll go nuts!
//
// Can anyone publish (put on a wiki)
// "The hitchhikers Guide to DXL Wildcard Parameters"
//----------------------------------------------------------
 
void f1(_a p1, _b p2, _c p3) {
    print("IN f1\n");
    print("p1 = " (string p1) "\n");
    print("p2 = " (int p2) "\n");
    print("p3 = " (char p3) "\n");
}
 
void f2(_k p1, _m p2, _n p3) {
    print("IN f2\n");
    print("p1 = " (string p1) "\n");
    print("p2 = " (int p2) "\n");
    print("p3 = " (char p3) "\n");
}
 
void f3(_x p1, _y p2) {
    print("IN f3\n");
    print("p1 = " (string p1) "\n");
    print("p2 = " (int p2) "\n");
}
 
void f4(_k p1) {
    print("IN f3\n");
    print("p1 = " (char p1) "\n");
}
 
f1("1", 2, '3');
f2("1", 2, '3');
f3("1", 2);
 
f4('3');

 


With offending line commented out:
Earschplittenloudenboomer
set(paramList, LabelA, ValueA) completed
IN f1
p1 = 1
p2 = 2
p3 = 3
IN f2
p1 = 1
p2 = 2
p3 = 3
IN f3
p1 = 1
p2 = 2
IN f3
p1 = 3

With offending line in:
-E- DXL: <C:\Program Files\IBM\Rational\DOORS\9.3/lib/dxl/addins/user/_issue.dxl:43> incorrect use of identifier (itemExists)
-I- DXL: All done. Errors reported: 1. Warnings reported: 0.

 

Re: Mysterious -E- DXL: incorrect use of identifier
Mathias Mamsch - Sun Aug 28 15:49:41 EDT 2011

SystemAdmin - Fri Aug 26 10:47:24 EDT 2011

Here is a more minimal code fragment to illustrate the Mysterious -E- DXL: incorrect use of identifier. No more cracks about "where's the comments" please. This is just a minimal fragment of code to illustrate a mysterious issue.
 

// Experiments
 
 
// Copyright © 2001 Telelogic AB. All rights reserved.
// See DOORS manuals for copying conditions.
// Copy this file to a different location before modifying it.
 
/*
  Experiments
*/
 
/*  Modification history:

    Date:       Who:    Description:
    1st May 95  rmm Added PC-specific path
    3 Sept 96   gv  Use standard filename routines.
*/
 
 
// *****************   CALLED FUNCTIONS  **************
 
bool itemExists(int p1, int p2, string p3, _x p4, int p5) {
    // SOME CODE ...
    return (true);
}
 
bool itemExists(int p1, int p2, string p3, _x p4) {
    int defaultP5 = 5;
    return itemExists(p1, p2, p3, p4, defaultP5);
}
 
// *****************   CALLED FROM **************
 
void setParam(int myList, string paramLabel, string paramValue) {
    bool containsKey = false;
    int p1 = 100;
    int p2 = 1000;
    //--------------------------------------------------------------------------
    // Why does the below yield -E- DXL: incorrect use of identifier (itemExists)
    //--------------------------------------------------------------------------
 
    // ****** UNCOMMENT THIS *******
//     containsKey = itemExists(p1, p2, "==", paramLabel); // FAILS
 
    //--------------------------------------------------------------------------
    // But if I copy label to labelA it works?
    //--------------------------------------------------------------------------
    string labelA = paramLabel;
    containsKey = itemExists(p1, p2, "==", labelA); // WORKS
 
    //--------------------------------------------------------------------------
    // If I cast the string parameter to a string it works?
    // Does DXL have early Alzheimer's disease?
    // It forgot what type paramLabel was?
    //--------------------------------------------------------------------------
    containsKey = itemExists(p1, p2, "==", (string paramLabel) ); // ALSO WORKS
 
    print("set(paramList, " paramLabel ", " paramValue ") completed\n");
}
 
print("Earschplittenloudenboomer\n");
 
int myList = 33;
setParam(myList, "LabelA", "ValueA");
 
 
// Extra credit bonus problem
// Can anyone tale a stab at "the decoder ring" for the crazy
// DXL underscore "wild-card" types?
// What do the letters mean?
// Does the chosen letter affect adjacent parameters?
 
//----------------------------------------------------------
// Output 2 -- Try different letters and orderings.
// You'll go nuts!
//
// Can anyone publish (put on a wiki)
// "The hitchhikers Guide to DXL Wildcard Parameters"
//----------------------------------------------------------
 
void f1(_a p1, _b p2, _c p3) {
    print("IN f1\n");
    print("p1 = " (string p1) "\n");
    print("p2 = " (int p2) "\n");
    print("p3 = " (char p3) "\n");
}
 
void f2(_k p1, _m p2, _n p3) {
    print("IN f2\n");
    print("p1 = " (string p1) "\n");
    print("p2 = " (int p2) "\n");
    print("p3 = " (char p3) "\n");
}
 
void f3(_x p1, _y p2) {
    print("IN f3\n");
    print("p1 = " (string p1) "\n");
    print("p2 = " (int p2) "\n");
}
 
void f4(_k p1) {
    print("IN f3\n");
    print("p1 = " (char p1) "\n");
}
 
f1("1", 2, '3');
f2("1", 2, '3');
f3("1", 2);
 
f4('3');

 


With offending line commented out:
Earschplittenloudenboomer
set(paramList, LabelA, ValueA) completed
IN f1
p1 = 1
p2 = 2
p3 = 3
IN f2
p1 = 1
p2 = 2
p3 = 3
IN f3
p1 = 1
p2 = 2
IN f3
p1 = 3

With offending line in:
-E- DXL: <C:\Program Files\IBM\Rational\DOORS\9.3/lib/dxl/addins/user/_issue.dxl:43> incorrect use of identifier (itemExists)
-I- DXL: All done. Errors reported: 1. Warnings reported: 0.

 

Lets boil that down to a real minimal example:
 

bool ff( _y p4) { return false }
 
// This produces the error 
// void test( string s1, string s2) { ff( s1 ); }
 
// This does NOT produce the error
void test( string s1, string s2) { ff( s2); }

 


This is almost certainly a bug in the DXL interpreter. I stumbled upon it a lot of times, so I guess that is one of the things to remember when dealing with underscore parameters. Regards, Mathias

 

 


Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

Re: Mysterious -E- DXL: incorrect use of identifier
llandale - Sun Aug 28 17:46:21 EDT 2011

SystemAdmin - Thu Aug 25 18:53:39 EDT 2011

Louie, I'm not sure what the too many compiler errors issue is. I don't have auto declare on and it compiles fine. (provided the one line is commented out).

With the line in I get

-E- DXL: <C:\Program Files\IBM\Rational\DOORS\9.3/lib/dxl/addins/user/_issue.dxl:69> incorrect use of identifier (itemExists)
-I- DXL: All done. Errors reported: 1. Warnings reported: 0.

With the line commented out I get

Earschplittenloudenboomer
set(paramList, LabelA, ValueA) completed
IN f1
p1 = 1
p2 = 2
p3 = 3
IN f2
p1 = 1
p2 = 2
p3 = 3
IN f3
p1 = 1
p2 = 2
IN f3
p1 = 3

Regarding:
Don't see the point of all these 'structures' and 'addr_' and '_x' flexible data types, other than to feel clever and make the code read-only; and it seems not even writable. The lack of comments supports this position. Don't bother claiming it "should" work in a "perfect" world; because it doesn't matter and it isn't. Karma and Murphy are working against you here.

This is only a code fragment with the minimal code in place to illustrate the issue. Stuff like
SPP_FromClauseType defaultFromClause = (SPP_FromClauseType addr_ 1);
is just to get a compilable example without extra source files.
Just to see if it had anything to do with perm clashes, I renamed:

label to paramLabel
value to paramValue
set() to setParam()

and still had the same
-E- DXL: <C:\Program Files\IBM\Rational\DOORS\9.3/lib/dxl/addins/user/_issue.dxl:69> incorrect use of identifier (itemExists)

The entire code that compiles is:

// Experiments
 
 
// Copyright © 2001 Telelogic AB. All rights reserved.
// See DOORS manuals for copying conditions.
// Copy this file to a different location before modifying it.
 
/*
  Experiments
*/
 
/*  Modification history:

    Date:       Who:    Description:
    1st May 95  rmm Added PC-specific path
    3 Sept 96   gv  Use standard filename routines.
*/
 
 
// *****************   CUSTOM TYPE FRAGMENT  **************
struct SPPType {}
struct SPP_FinderClauseType {}
struct SPP_FromClauseType {}
 
bool itemExists(SPPType this,
                 SPP_FinderClauseType finderClause,
                 string registeredCompareFunction,
                 _x queryValue,
                 SPP_FromClauseType fromHere) {
    int qtyFound = 0;
 
    // SOME CODE ...
 
    return (qtyFound > 0);
}
 
bool itemExists(SPPType this,
                SPP_FinderClauseType finderClause,
                string registeredCompareFunction,
                _x queryValue) {
    SPP_FromClauseType defaultFromClause = (SPP_FromClauseType addr_ 1);
    return itemExists(this,                            //-
                       finderClause,                   //-
                       registeredCompareFunction,      //-
                       queryValue,                     //-
                       defaultFromClause );
}
 
 
// *****************   CALLED FROM **************
 
 
struct ParamListType {}
 
void setParam(ParamListType this, //-
              string        paramLabel, //-
              string        paramValue) {
    bool containsKey = false;
 
    SPPType spp = (SPPType addr_ 1); // In reality a custom type
    SPP_FinderClauseType finderClause = (SPP_FinderClauseType addr_ 1); // In reality a custom type
 
    //--------------------------------------------------------------------------
    // Why does this yield -E- DXL: incorrect use of identifier (itemExists)
    //--------------------------------------------------------------------------
 
    // ****** UNCOMMENT THIS *******
 
    // containsKey = itemExists(spp, finderClause, "==", paramLabel); // FAILS
 
    //--------------------------------------------------------------------------
    // But if I copy label to labelA it works?
    //--------------------------------------------------------------------------
    string labelA = paramLabel;
    containsKey = itemExists(spp, finderClause, "==", labelA); // WORKS
 
    containsKey = itemExists(spp, finderClause, "==", (string paramLabel) ); // ALSO WORKS
 
    print("set(paramList, " paramLabel ", " paramValue ") completed\n");
}
 
print("Earschplittenloudenboomer\n");
 
ParamListType paramList = (ParamListType addr_ 1);
setParam(paramList, "LabelA", "ValueA");
 
 
// Extra credit bonus problem
// Can anyone tale a stab at "the decoder ring" for the crazy
// DXL underscore "wild-card" types?
// What do the letters mean?
// Does the chosen letter affect adjacent parameters?
 
//----------------------------------------------------------
// Output 2 -- Try different letters and orderings.
// You'll go nuts!
//----------------------------------------------------------
 
void f1(_a p1, _b p2, _c p3) {
    print("IN f1\n");
    print("p1 = " (string p1) "\n");
    print("p2 = " (int p2) "\n");
    print("p3 = " (char p3) "\n");
}
 
void f2(_k p1, _m p2, _n p3) {
    print("IN f2\n");
    print("p1 = " (string p1) "\n");
    print("p2 = " (int p2) "\n");
    print("p3 = " (char p3) "\n");
}
 
void f3(_x p1, _y p2) {
    print("IN f3\n");
    print("p1 = " (string p1) "\n");
    print("p2 = " (int p2) "\n");
}
 
void f4(_k p1) {
    print("IN f3\n");
    print("p1 = " (char p1) "\n");
}
 
f1("1", 2, '3');
f2("1", 2, '3');
f3("1", 2);
 
f4('3');


{code}

Must have compiled your whole code not noticing when the output started.

Didn't mean to suggest you 'should' have known, but I think when you clarify with 'string' it works. I have no idea how a bug like that could get into the interpreter.

But, if you've seen 100,000 DXL errors you get sort of used to the fixes. When it complains about 'identifier' then the two prime guesses are:

1 you are using a variable same name as a built-in function (Mathias 1st guess which was also mine) 'label' in this case.
2 you are using a keyword
3 you have more than one thing with exactly the same name, such as function "string A()" and variable "bool A", and it gets confused.

OK 3. But by casting you can get rid of 1 and 3.

So there's a bug and an easy work around.

Didn't mean to suggest that you never use clever coding, just that the vast majority of the time you should spend a little more time to code it 'traditionally' so the next dude can read it.

  • Louie

Re: Mysterious -E- DXL: incorrect use of identifier
SystemAdmin - Mon Aug 29 12:19:42 EDT 2011

llandale - Sun Aug 28 17:46:21 EDT 2011
Must have compiled your whole code not noticing when the output started.

Didn't mean to suggest you 'should' have known, but I think when you clarify with 'string' it works. I have no idea how a bug like that could get into the interpreter.

But, if you've seen 100,000 DXL errors you get sort of used to the fixes. When it complains about 'identifier' then the two prime guesses are:

1 you are using a variable same name as a built-in function (Mathias 1st guess which was also mine) 'label' in this case.
2 you are using a keyword
3 you have more than one thing with exactly the same name, such as function "string A()" and variable "bool A", and it gets confused.

OK 3. But by casting you can get rid of 1 and 3.

So there's a bug and an easy work around.

Didn't mean to suggest that you never use clever coding, just that the vast majority of the time you should spend a little more time to code it 'traditionally' so the next dude can read it.

  • Louie

Louie and Mathias -- Thanks for the responses.

Per Louie, I avoid the _x types wherever possible. I never expose and _x parameters to external interface (for users of code). I only use wild parameters internally when I would normally have to replicate (and maintain) the same algorithm for multiple parameter types. If I use them at all I carefully document whats going on.

Mathias, I verified your simple example illustrates the -E- DXL: incorrect use of identifier bug.

So I think we all concur this is a DXL interpreter bug. What still is not clear to me is "what is the fatal pattern where the -E- DXL: incorrect use of identifier rears its ugly head?"

I know we'll never see a perfect word here but I would like to walk away with "The DXL interpreter gets confused when (fill in the blank). To fix the issue do (fill in the blank)."

Here is my take. Tell me if you concur.

"Any parameter in a parameter list other than the last,
must be re-resolved or explicitly cast prior to being used as a
function parameter whose type is "wild" (e.g., _x)."
 

char resolve(char p1) {
    print "Called resolve(char)\n";
    return p1;
}
 
 
int resolve(int p1) {
    print "Called resolve(int)\n";
    return p1;
}
 
 
string resolve(string p1) {
    print "Called resolve(string)\n";
    return p1;
}
 
 
real resolve(real p1) {
    print "Called resolve(real)\n";
    return p1;
}
 
 
void ff( _x underscoreX) { print "underscoreX is " (string underscoreX) "\n" }
 
// This does NOT produce the error
void test( string s1, string s2, string s3, string s4, string s5 ) {
    // DXL seems to still know the type of each parameter because it
    // picks the correct signature of resolve.
    //
    // All of these work.
    print "\n*** resolve series ***\n";
    ff( resolve(s1) );
    ff( resolve(s2) );
    ff( resolve(s3) );
    ff( resolve(s4) );
    ff( resolve(s5) );
 
    // All of these work.
    print "\n*** local variable series ***\n";
    string s1A = s1;
    string s2A = s2;
    string s3A = s3;
    string s4A = s4;
    string s5A = s5;
    ff( s1A );
    ff( s2A );
    ff( s3A );
    ff( s4A );
    ff( s5A );
 
    // All of these work.
    print "\n*** explicit cast series ***\n";
    ff( (string s1) );
    ff( (string s2) );
    ff( (string s3) );
    ff( (string s4) );
    ff( (string s5) );
 
    print "\n*** direct use of parameter from parameter list series ***\n";
    // Only the last parameter int the parameter list
    // works without "help" of some sort
//    ff( s1 );
//    ff( s2 );
//    ff( s3 );
//    ff( s4 );
    ff( s5 );
 
// Conclusion?  Any parameter in a parameter list other than the last,
// must be re-resolved or explicitly cast prior to being used as a
// function parameter whose type is "wild" (e.g., _x).
}
 
test("A", "B", "C", "D", "E");

Re: Mysterious -E- DXL: incorrect use of identifier
Mathias Mamsch - Mon Aug 29 19:14:49 EDT 2011

SystemAdmin - Mon Aug 29 12:19:42 EDT 2011

Louie and Mathias -- Thanks for the responses.

Per Louie, I avoid the _x types wherever possible. I never expose and _x parameters to external interface (for users of code). I only use wild parameters internally when I would normally have to replicate (and maintain) the same algorithm for multiple parameter types. If I use them at all I carefully document whats going on.

Mathias, I verified your simple example illustrates the -E- DXL: incorrect use of identifier bug.

So I think we all concur this is a DXL interpreter bug. What still is not clear to me is "what is the fatal pattern where the -E- DXL: incorrect use of identifier rears its ugly head?"

I know we'll never see a perfect word here but I would like to walk away with "The DXL interpreter gets confused when (fill in the blank). To fix the issue do (fill in the blank)."

Here is my take. Tell me if you concur.

"Any parameter in a parameter list other than the last,
must be re-resolved or explicitly cast prior to being used as a
function parameter whose type is "wild" (e.g., _x)."
 

char resolve(char p1) {
    print "Called resolve(char)\n";
    return p1;
}
 
 
int resolve(int p1) {
    print "Called resolve(int)\n";
    return p1;
}
 
 
string resolve(string p1) {
    print "Called resolve(string)\n";
    return p1;
}
 
 
real resolve(real p1) {
    print "Called resolve(real)\n";
    return p1;
}
 
 
void ff( _x underscoreX) { print "underscoreX is " (string underscoreX) "\n" }
 
// This does NOT produce the error
void test( string s1, string s2, string s3, string s4, string s5 ) {
    // DXL seems to still know the type of each parameter because it
    // picks the correct signature of resolve.
    //
    // All of these work.
    print "\n*** resolve series ***\n";
    ff( resolve(s1) );
    ff( resolve(s2) );
    ff( resolve(s3) );
    ff( resolve(s4) );
    ff( resolve(s5) );
 
    // All of these work.
    print "\n*** local variable series ***\n";
    string s1A = s1;
    string s2A = s2;
    string s3A = s3;
    string s4A = s4;
    string s5A = s5;
    ff( s1A );
    ff( s2A );
    ff( s3A );
    ff( s4A );
    ff( s5A );
 
    // All of these work.
    print "\n*** explicit cast series ***\n";
    ff( (string s1) );
    ff( (string s2) );
    ff( (string s3) );
    ff( (string s4) );
    ff( (string s5) );
 
    print "\n*** direct use of parameter from parameter list series ***\n";
    // Only the last parameter int the parameter list
    // works without "help" of some sort
//    ff( s1 );
//    ff( s2 );
//    ff( s3 );
//    ff( s4 );
    ff( s5 );
 
// Conclusion?  Any parameter in a parameter list other than the last,
// must be re-resolved or explicitly cast prior to being used as a
// function parameter whose type is "wild" (e.g., _x).
}
 
test("A", "B", "C", "D", "E");

Not quite... But keep trying to explain this rather complex symbol lookup behaviour ;-)
 

bool ff( _y p4, int p5) { return false }
 
void test1( string s1, string s2) { ff(  s2, 5); } // Works
void test2( string s1, string s2) { ff(  s1, 5); } // Works 
 
bool gg( int p5, _y p4) { return false }
 
void test3( string s1, string s2) { gg(  5, s2); } // Works
// void test4( string s1, string s2) { gg(  5, s1); } // Does not work ;-)

 


Why would you not want to settle for: Sometimes if you pass stuff to a function with underscore parameter you get a nasty incorrect use error. To resolve tell the DXL interpreter your parameter types explicitly.

Regards, Mathias

 

 


Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

Re: Mysterious -E- DXL: incorrect use of identifier
SystemAdmin - Mon Aug 29 20:24:48 EDT 2011

Mathias Mamsch - Mon Aug 29 19:14:49 EDT 2011

Not quite... But keep trying to explain this rather complex symbol lookup behaviour ;-)
 

bool ff( _y p4, int p5) { return false }
 
void test1( string s1, string s2) { ff(  s2, 5); } // Works
void test2( string s1, string s2) { ff(  s1, 5); } // Works 
 
bool gg( int p5, _y p4) { return false }
 
void test3( string s1, string s2) { gg(  5, s2); } // Works
// void test4( string s1, string s2) { gg(  5, s1); } // Does not work ;-)

 


Why would you not want to settle for: Sometimes if you pass stuff to a function with underscore parameter you get a nasty incorrect use error. To resolve tell the DXL interpreter your parameter types explicitly.

Regards, Mathias

 

 


Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

RE:

Why would you not want to settle for: Sometimes if you pass stuff to a function with underscore parameter you get a nasty incorrect use error. To resolve tell the DXL interpreter your parameter types explicitly.

It seems ridiculous to have to re-tell DXL what the type of an explicitly typed parameter is a second time, but what you suggested was going to be my recommended solution, but I wanted to identify the fatal pattern while it was fresh in my mind.

Looks like identifying the fatal pattern(s) is a project in itself.

Re: Mysterious -E- DXL: incorrect use of identifier
llandale - Mon Aug 29 21:45:05 EDT 2011

SystemAdmin - Mon Aug 29 20:24:48 EDT 2011
RE:

Why would you not want to settle for: Sometimes if you pass stuff to a function with underscore parameter you get a nasty incorrect use error. To resolve tell the DXL interpreter your parameter types explicitly.

It seems ridiculous to have to re-tell DXL what the type of an explicitly typed parameter is a second time, but what you suggested was going to be my recommended solution, but I wanted to identify the fatal pattern while it was fresh in my mind.

Looks like identifying the fatal pattern(s) is a project in itself.

I think it far more probably that the early DXL folks were few rather than many building a certified interpreter. There are a few holes like this, doesn't seem like much of a chore to insert 'string' when you encounter the error.

I think far more serious is this DXL:

void  FF(string InString)
{  print "FF> [" InString "]\n"
   return(InString InString)
}
string R = "A" FF("B") "~XYZ" FF("~C") "--done--"
print ">>>" R "<<<\n"


Now that is a bug that seems impossible to have written and also impossible to not have fixed. But they classified it as a "feature" some years ago.

 

 

  • Louie

 

 

Re: Mysterious -E- DXL: incorrect use of identifier
pommCannelle - Thu Dec 12 08:50:29 EST 2013

SystemAdmin - Mon Aug 29 20:24:48 EDT 2011
RE:

Why would you not want to settle for: Sometimes if you pass stuff to a function with underscore parameter you get a nasty incorrect use error. To resolve tell the DXL interpreter your parameter types explicitly.

It seems ridiculous to have to re-tell DXL what the type of an explicitly typed parameter is a second time, but what you suggested was going to be my recommended solution, but I wanted to identify the fatal pattern while it was fresh in my mind.

Looks like identifying the fatal pattern(s) is a project in itself.

(
Mathias is right ... a simple explicit cast allows the complialtion ...
containsKey = itemExists(spp, finderClause, "==", label) -> containsKey = itemExists(spp, finderClause, "==", label"") ...
)

Re: Mysterious -E- DXL: incorrect use of identifier
pommCannelle - Thu Dec 12 08:58:51 EST 2013

llandale - Mon Aug 29 21:45:05 EDT 2011

I think it far more probably that the early DXL folks were few rather than many building a certified interpreter. There are a few holes like this, doesn't seem like much of a chore to insert 'string' when you encounter the error.

I think far more serious is this DXL:

void  FF(string InString)
{  print "FF> [" InString "]\n"
   return(InString InString)
}
string R = "A" FF("B") "~XYZ" FF("~C") "--done--"
print ">>>" R "<<<\n"


Now that is a bug that seems impossible to have written and also impossible to not have fixed. But they classified it as a "feature" some years ago.

 

 

  • Louie

 

 

(
Perhaps the interpreter needs some help ....
This code works fine:

string FF(string InString) {
   print "FF> [" InString "]\n"
   return(InString InString)
}

string R = "A" (FF("B")) "~XYZ" (FF("~C")) "--done--"
print  ">>>" R "<<<\n"

o;)
)

Re: Mysterious -E- DXL: incorrect use of identifier
pommCannelle - Thu Dec 12 09:27:31 EST 2013

Mathias Mamsch - Sun Aug 28 15:49:41 EDT 2011

Lets boil that down to a real minimal example:
 

bool ff( _y p4) { return false }
 
// This produces the error 
// void test( string s1, string s2) { ff( s1 ); }
 
// This does NOT produce the error
void test( string s1, string s2) { ff( s2); }

 


This is almost certainly a bug in the DXL interpreter. I stumbled upon it a lot of times, so I guess that is one of the things to remember when dealing with underscore parameters. Regards, Mathias

 

 


Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

( You can avoid this behavior using the undefined number of arguments style ....

bool ff ( _a var ){ return true }
void test ( string s[] ) { print ff ( s[0] ) }
test ( "1", "2" )

If you can explain that .... o;)
)
 

Re: Mysterious -E- DXL: incorrect use of identifier
llandale - Thu Dec 12 17:00:32 EST 2013

pommCannelle - Thu Dec 12 09:27:31 EST 2013

( You can avoid this behavior using the undefined number of arguments style ....

bool ff ( _a var ){ return true }
void test ( string s[] ) { print ff ( s[0] ) }
test ( "1", "2" )

If you can explain that .... o;)
)
 

I think these explanations of DXL "features" is impossible, since the DXL interpretor has been around for 35 years and been tested by 10s of 1000s of folks in 100s of different sub-languages etc, just like "C".

-Louie